Resume Driven Development

#JaiLu un excellent article sur NATS : NATS de A à Y du blog Une tasse de café de Quentin Joly.

J'aime beaucoup les fonctionnalités cli de NATS, très pratiques pour faire des démos ou des tests.

J'y ai découvert les requêtes synchrones de NATS : Core NATS - Request-Reply.

À la fin de l'article, j'ai découvert Nex (NATS Execution Engine) :

The NATS Execution Engine (we'll just call it Nex most of the time) is an optional add-on to NATS that overlays your existing NATS infrastructure, giving you the ability to deploy and run workloads.

...

While you can build virtually any kind of application with Nex, the core building blocks are made up of two fundamental types of workloads: services and functions.

...

Nex functions are small and can be deployed either as Javascript functions or as WebAssembly modules.

Je découvre aussi que Nex utilise Firecracker.

Je suis un peu embêté, car je réalise que cela fait 2 ans que j'ai très envie d'utiliser NATS. J'espère ne pas tomber prochainement dans les travers du Resume Driven Development 🙈.

À la suite de la lecture de cet article, j'ai offert un petit café à Quentin Joly.

#JaiLu la note de David Larlet nommée Initiateurs et mainteneurs.

There are two roles for any project: starters and maintainers. People may play both roles in their lives, but for some reason I’ve found that for a single project it’s usually different people. Starters are good at taking a big step in a different direction, and maintainers are good at being dedicated to keeping the code alive.

…

I am definitely a starter. I tend to be interested in a lot of various things, instead of dedicating myself to a few concentrated areas. I’ve maintained libraries for years, but it’s always a huge source of guilt and late Friday nights to catch up on a backlog of issues.

Starters and Maintainers (cache)

Je suis également un initiateur. J’aime créer de nouvelles choses en expérimentant des usages et des techniques. Lorsque je me retrouve dans un rôle de mainteneur, j’ai tendance à complexifier l’existant et à le rendre moins stable par ma soif d’apprendre de nouvelles choses. Or l’apprentissage nait de l’échec et du test des limites. C’est assez désastreux pour les projets et je pense que l’engouement pour les microservices est un complot des initiateurs en mal d’expérimentations au sein d’applications à maintenir. À moins que la maintenance soit un vestige du passé (cache).

-- from

Ces réflexions résonnent profondément en moi 🤗, car ce sont des questions et des pensées qui m'habitent depuis de nombreuses années.

« j’ai tendance à complexifier l’existant et à le rendre moins stable par ma soif d’apprendre de nouvelles choses »

Pour éviter cette tendance à complexifier l’existant, j'utilise la stratégie suivante. Lorsque je ressens le besoin d'expérimenter ou d'apprendre quelque chose de nouveau, je le fais au travers des side projects personnels ou dans le cadre de POC (Proof of Concept) et Spike officiellement décidés en équipe. C'est entre autres pour cette raison que j'avais proposé de mettre en place les Spike and Learn Day.

Cette approche me permet de satisfaire ma curiosité et mon envie d'apprendre, tout en maintenant l'utilisation de Boring Technology pour les projets critiques ou ceux menés en équipe. Ainsi, je parviens à éviter le piège du Resume Driven Development.

J'aime bien la distinction suivante :

« There are two roles for any project: starters and maintainers »

Jusqu'à présent, j'ai tendance à utiliser le terme solo développeurs pour les "starters" et team développeurs pour les "maintainers".

Petite anecdote amusante : lors de mon expérience chez Spacefill, j'avais proposé de nommer le rôle des développeurs d'expérience au sein de l'équipe les "maintainers" 😉.

« C’est assez désastreux pour les projets et je pense que l’engouement pour les microservices est un complot des initiateurs en mal d’expérimentations au sein d’applications à maintenir. »

C'est une réflexion que j'ai moi-même eue par le passé.

Je crois en effet que les solo développeurs apprécient particulièrement les microservices et les multi repositories car cela leur permet d'éviter les contraintes d'équipes.
Cela leur permet d'explorer des nouveaux langages et frameworks et d'échaper aux revues de code.

À mes yeux, cette approche favorise davantage l'individualisme que la cohésion d'équipe.

J'ai également remarqué que c'est souvent lors des phases de storming du modèle de Tuckman que les développeurs semblent se tourner vers les microservices comme une forme d'évitement des défis collectifs. Cette stratégie peut sembler séduisante, mais elle risque de renforcer les silos et de freiner la collaboration au sein de l'équipe 🤔.

Je pense que depuis 2013 environ, je me classe dans la catégorie des artisans développeurs de type conservateurs.

Je m'efforce de suivre une une doctrine centrée sur le principe du Choose Boring Technology.
Je ne crois plus aux "techniques miracles" (No Silver Bullet).

J'ai vu trop de projet souffrir de pratique telles que le Resume Driven Development ou de Cargo cult programming.

Voir aussi : Keep it simple, stupid le plus longtemps possible.